home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000135_owner-urn-ietf _Thu Oct 31 08:41:34 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA12102 for urn-ietf-out; Thu, 31 Oct 1996 08:41:34 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA12097 for <urn-ietf@services.bunyip.com>; Thu, 31 Oct 1996 08:41:31 -0500
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA21856  (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 08:41:26 -0500
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <00846-0@josef.ifi.unizh.ch>; Thu, 31 Oct 1996 14:38:58 +0100
  7. Subject: Re: [URN] New syntax draft (was: no subject)
  8. To: gjw@wnetc.com (Gregory J. Woodhouse)
  9. Date: Thu, 31 Oct 1996 14:38:57 +0100 (MET)
  10. Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com
  11. In-Reply-To: <Pine.SGI.3.95.961031050249.19154D-100000@shellx.best.com> from "Gregory J. Woodhouse" at Oct 31, 96 05:15:43 am
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 2937
  16. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  17. Message-Id: <"josef.ifi..493:31.09.96.13.39.00"@ifi.unizh.ch>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Gregory Woodhouse wrote:
  24.  
  25. >I'm also concerned because decoding requires knowledge that the string
  26. >being decoded is UTF-8.
  27.  
  28. Not exactly. It is very rare that a string that is not UTF-8 looks
  29. like an UTF-8 string.
  30.  
  31. >I said before that I wasn't terribly excited about
  32. >using RFC 1522 style encodings,
  33.  
  34. Me neither! "charset" is okay for long mails, and RFC 1522 was unavoidable
  35. at the time it was created, but now we have better solutions.
  36.  
  37. >but it seems essential in this case because
  38. >otherwise the UA has no way of knowing (except by guessing) that the string
  39. >is encoded UTF-8 and not just an ASCII string.
  40.  
  41. This difference is always absolutely clear! A string that only contains
  42. bytes with the high bit '0' (7-bit bytes) is ASCII. As soon as a high
  43. bit is set to '1', it's not ASCII anymore. It may be UTF-8, or may not.
  44.  
  45. >It is conceivable that some
  46. >URN schemes will allow the sequences like %20%1E or whatever, so this could
  47. >be a real problem.
  48.  
  49. Well, %20 is a space, which is ASCII, but should be escaped.
  50. %1E is a control character (record separator), never appears in UTF-8,
  51. and strictly speaking is also not part of ASCII.
  52.  
  53. >Another thought: What if someone wants to come along an
  54. >do %hhhh style encoding of UTF-16? Will this be mistaken for encoded UTF-8?
  55.  
  56. Well, anybody can come along and propose new weird syntax rules for
  57. URNs. Hopefully, nobody will listen to him/her. And these rules
  58. won't comply with the official URN syntax we are working on here.
  59.  
  60. Actually, I don't think that anybody will get the idea of using UTF-16
  61. when UTF-8 is proposed. It's Unicode/ISO 10646 in both cases, the transform
  62. is easy, and people dealing with Unicode and stuff know that things such
  63. as URNs, with ASCII backwards compatibility requirements, are best
  64. handled using UTF-8.
  65.  
  66. The things we have to worry about more are people that come along
  67. and say they want to use something else than Unicode/ISO 10646,
  68. or at least want to be able to use something else, because for
  69. some reasons, they are against Unicode, or they think it should
  70. just be one of many encodings.
  71. Also, what we have to worry about are cases where it's difficult
  72. to know what native character encoding is used, so that it is
  73. difficult to convert to Unicode and UTF-8 even if you wanted.
  74. ftp is a typical case of this.
  75.  
  76. Anyway, even the two cases above are well handled in the draft.
  77. We tell them that if they really need to, they can use something
  78. else than UTF-8. Maybe we should tell them a little bit clearer
  79. that if they do that, they are not supposed to get any much
  80. of support by general tools, i.e. their URNs will just show
  81. up as %HH%HH..., and the users will have to type them in like
  82. this, and accidentally, some of it may be interpreted as UTF-8
  83. and be displayed as such, but they cannot have their users
  84. type native characters into a browser and expect that the
  85. browser does the right thing (because it would in this case
  86. convert to UTF-8).
  87.  
  88. Regards,    Martin.